Lab. XX - Laboratorium problemowe 3 - “Robot kurierski na przejściu dla pieszych”

1. Laboratoria problemowe

W ramach laboratorium problemowego stawiany jest przed Państwem problem, zagadnienie, które wymaga pracy własnej, szukania rozwiązań, kreatywnego podejścia.

Efektem tego laboratorium nie musi być rozwiązanie problemu. Skupiamy się tutaj na możliwych podejściach, rozważaniu co może zadziałać a co nie zadziała, jakie potencjalne problemy możemy napotkać.

Wynikiem końcowym ma być krótki raport (więcej na dole instrukcji) oraz ewentualnie program realizujący rozwiązanie problemu. Raport będzie oceniany jak standardowe zadanie domowe, natomiast za implementację możliwe jest do uzyskania dodatkowo do 5 punktów.

2. Problem

Dany jest robot kurierski (dostawczy), podobny do robotów, które rozwożą przesyłki po chodnikach. Robot ma napęd różnicowy i jest wyposażony w: - kamerę RGB skierowaną do przodu, - lidar 3D o 16 warstwach (360° w poziomie, ±15° w pionie, zasięg 30 m), - IMU oraz odometrię kół.

Robot stoi na chodniku przed przejściem dla pieszych z sygnalizacją świetlną. Jego zadaniem jest przejechać na drugą stronę ulicy, do punktu docelowego na przeciwległym chodniku. Przejazd musi być bezpieczny i zgodny z przepisami, czyli robot: - wjeżdża na jezdnię tylko przy ciągłym zielonym świetle dla pieszych, - porusza się po pasach, - nie zderza się z pieszymi, którzy chodzą po chodnikach i również korzystają z przejścia, - nie zderza się z samochodami.

UWAGA! Zdarza się, że samochód przejeżdża na czerwonym świetle, kiedy dla pieszych pali się zielone. Kierowcy nie hamują przed robotem.

Geometria otoczenia (położenie jezdni, przejścia i punktu docelowego) jest znana i opisana w punkcie 4. Robot nie zna natomiast stanu sygnalizacji ani położeń pieszych i samochodów - musi je określić na podstawie własnych czujników. W szczególności stan sygnalizacji należy rozpoznać z obrazu z kamery.

Zadanie powinno być realizowane jako akcja, której celem jest przejazd na drugą stronę ulicy, a wynikiem informacja, czy przejazd się udał.

3. Przygotowanie środowiska

Przed przystąpieniem do pracy należy przygotować środowisko: Instrukcja przygotowania środowiska do zajęć. Obraz bazuje na osrf/ros:jazzy-desktop-full (ROS 2 Jazzy Jalisco) z symulatorem Gazebo Harmonic. Podczas budowania obrazu pobierane są modele 3D (samochody, piesi, drzewa) z Gazebo Fuel, więc pierwsze budowanie może chwilę potrwać.

Domyślnie kontener nosi nazwę ARM_XX.

UWAGA! Skrypty po uruchomieniu usuwają kontener o takiej nazwie przed utworzeniem nowego.

Korzystanie z kontenera

Po każdym ponownym uruchomieniu komputera, proszę pamiętać o wywoływaniu:

xhost +local:root

Nowy terminal można dołączyć do kontenera korzystając z polecenia:

docker exec -it ARM_XX bash

Komunikacja w sieci

W tym obrazie ROS 2 i Gazebo domyślnie komunikują się tylko w obrębie jednego komputera (w pliku ~/.bashrc ustawione są zmienne ROS_AUTOMATIC_DISCOVERY_RANGE=LOCALHOST i GZ_IP=127.0.0.1). Dzięki temu symulacje różnych osób w tej samej sieci lokalnej się nie mieszają i nie trzeba ustawiać zmiennej ROS_DOMAIN_ID.

Jeżeli program ma działać na innym komputerze niż symulacja (np. na własnym laptopie), w terminalach na obu komputerach należy zezwolić na komunikację w sieci i ustawić tę samą, unikalną wartość ROS_DOMAIN_ID z zakresu 0-100:

export ROS_AUTOMATIC_DISCOVERY_RANGE=SUBNET
export ROS_DOMAIN_ID=10  # przykładowa wartość

Sugerowane jest użycie dwóch ostatnich cyfr numeru IP komputera jako wartości ROS_DOMAIN_ID, aby uniknąć konfliktów z innymi użytkownikami w sieci. Aby sprawdzić swój adres IP, można użyć polecenia:

ip addr show

Jeżeli na jednym komputerze działa kilka symulacji (np. w kilku kontenerach), można je dodatkowo rozdzielić, ustawiając w każdym kontenerze inną wartość zmiennej GZ_PARTITION (węzły Gazebo widzą się nawzajem tylko w obrębie tej samej partycji). Wartość musi być taka sama we wszystkich terminalach, w których korzysta się z danej symulacji, dlatego najlepiej dopisać ją do pliku ~/.bashrc:

echo 'export GZ_PARTITION=<wybrana_nazwa>' >> ~/.bashrc  # np. arm_10

4. Uruchomienie symulacji

Symulację z paczki crosswalk_sim (repozytorium arm_crosswalk_sim) można uruchomić poleceniem

cd /arm_ws
source install/setup.bash
ros2 launch crosswalk_sim sim.launch.py

Pierwsze uruchomienie może trochę potrwać, wymagana jest odrobina cierpliwości.

Razem z symulacją uruchamiany jest RViz z obrazem z kamery, chmurą punktów z lidaru i mapą ulicy. Można go wyłączyć argumentem rviz:=false, a okno Gazebo argumentem gui:=false (czujniki nadal działają). W oknie Gazebo, po prawej stronie, widoczny jest obraz z kamery robota.

Świat

• Ulica biegnie wzdłuż osi x układu world, a przejście dla pieszych (pasy o szerokości 4 m, x od -2 do 2 m) leży w x = 0.
• Jezdnia zajmuje y od -3,5 do 3,5 m, z jednym pasem ruchu w każdą stronę. Ruch jest prawostronny: samochody na pasie y < 0 jadą w kierunku +x, a na pasie y > 0 w kierunku -x.
• Chodniki leżą w 3,5 m < |y| < 7,5 m. Krawężniki mają 10 cm wysokości i są obniżone przy przejściu.
• Robot startuje w punkcie (0; -5,2) zwrócony w kierunku +y. Punkt docelowy to (0; 6), publikowany również na topicu /crosswalk/goal.
• Publikowana jest transformacja world → odom (pozycja startowa robota), więc położenie robota w układzie świata wynika z odometrii.

Sygnalizator dla pieszych, który powinien obserwować robot, stoi po drugiej stronie ulicy (x ≈ -2,6 m). Czerwone światło jest u góry, zielone u dołu:

Cykl sygnalizacji (wartości domyślne): - zielone dla samochodów: 25 s, - żółte dla samochodów: 3 s, - czerwone dla wszystkich: 2 s, - zielone dla pieszych: 12 s, - migające zielone dla pieszych: 4 s (nie należy już wjeżdżać na przejście), - czerwone dla wszystkich: 2 s, - czerwone z żółtym dla samochodów: 1,5 s.

Czujniki i sterowanie

W odróżnieniu od TurtleBota3 z poprzednich zajęć, robot przyjmuje na topicu /cmd_vel wiadomości geometry_msgs/msg/Twist. Robotem można sterować z klawiatury:

ros2 run teleop_twist_keyboard teleop_twist_keyboard

Scenariusze i parametry

Natężenie ruchu pieszych i samochodów oraz częstość przejazdów na czerwonym świetle można zmieniać. Dostępne są gotowe scenariusze easy (mały ruch, bez przejazdów na czerwonym), default, hard (duży ruch, częste przejazdy na czerwonym, piesi przechodzący na czerwonym) oraz runner_test (przejazd na czerwonym w każdym cyklu świateł):

ros2 launch crosswalk_sim sim.launch.py scenario:=hard

Pojedyncze parametry można nadpisać argumentem params, a argument seed pozwala powtórzyć ten sam przebieg symulacji:

ros2 launch crosswalk_sim sim.launch.py seed:=42 params:="red_runner.probability=0.8 red_runner.window=[2,6] pedestrians.crossing_rate=15"

Najważniejsze parametry: - pedestrians.crossing_rate / pedestrians.sidewalk_rate - liczba pieszych na minutę, którzy przechodzą przez ulicę / idą wzdłuż chodnika, - cars.rate - liczba samochodów na minutę na każdym pasie, - red_runner.probability - prawdopodobieństwo, że w danym cyklu świateł któryś samochód przejedzie na czerwonym, - red_runner.window - przedział czasu (w sekundach, liczony od zapalenia się zielonego dla pieszych), w którym taki samochód dojeżdża do przejścia.

Pełna lista parametrów znajduje się w pliku default.yaml.

Sędzia i topici /debug

Symulacja ocenia każdą próbę przejazdu. W terminalu, w którym uruchomiono symulację, wypisywane są zdarzenia: - wjazd na jezdnię (wraz ze stanem świateł), - naruszenia przepisów (wjazd na czerwonym, zjazd poza pasy), - zderzenia z samochodami i pieszymi, - sytuacje, w których samochód przejechał bardzo blisko robota, - wynik przejazdu (SUCCESS lub FAILED).

Piesi i samochody nie mają fizycznych kolizji - przejeżdżają przez robota, a zderzenie jest zgłaszane przez sędziego.

Kolejną próbę można rozpocząć bez restartowania symulacji. Poniższe polecenie przenosi robota z powrotem na pozycję startową:

ros2 topic pub --once /crosswalk/reset std_msgs/msg/Empty

Topici z prefiksem /debug/ zawierają informacje niedostępne dla prawdziwego robota: stan świateł, położenia wszystkich pieszych i samochodów, zdarzenia sędziego. Rozwiązanie nie może z nich korzystać. Można ich natomiast używać do sprawdzania dokładności proponowanego systemu, np. porównując rozpoznany stan świateł z /debug/crosswalk/ground_truth/pedestrian_light, a wyniki przejazdów odczytując z /debug/crosswalk/events.

5. Zadanie do samodzielnej realizacji

W ramach zajęć należy zaproponować sposób rozwiązania problemu postawionego w punkcie 2.

Efektem ma być przygotowanie raportu, który będzie zawierał proponowaną strukturę programu (wraz z node’ami i topicami, które będą one wymieniać), paczki z sieci, które można wykorzystać do realizacji zadania oraz opis potencjalnych problemów, na które można napotkać. W raporcie warto odnieść się w szczególności do: - rozpoznawania stanu sygnalizacji na podstawie obrazu z kamery, - wykrywania i śledzenia pieszych i samochodów, - podejmowania decyzji o wjeździe na jezdnię, - zachowania robota w sytuacjach niebezpiecznych, np. gdy samochód przejeżdża na czerwonym świetle, a robot jest już na jezdni.

Raport powinien mieć następujące elementy:

• Cel i założenia – krótki opis problemu oraz przyjętych ograniczeń.
• Strategia działania – najważniejsze kroki algorytmu oraz podział odpowiedzialności między node’ami.
• Schematy i diagramy – diagramy blokowe, diagramy przepływu danych między node’ami itp.
• Wykorzystane narzędzia – biblioteki, paczki ROS2 i inne zasoby zewnętrzne.
• Potencjalne ryzyka – spodziewane trudności, sposoby ich weryfikacji lub obejścia.
• Wnioski – podsumowanie, możliwe kierunki dalszego rozwoju.

Program

Opcjonalnie, można również przygotować program realizujący postawione zadanie (wraz z jego opisem w ramach raportu). Za implementację można otrzymać dodatkowo do 5 punktów. Działanie programu warto sprawdzić w scenariuszach easy, default i hard.

_{Autor: Kamil Młodzikowski}